Lawful Interception (LI) allows Law Enforcement Agencies (LEAs) to obtain communication network data for the purpose of analysis or gathering evidence. The data typically includes details of signalling, such as called and calling parties, and in some instances the contents of the call itself.
Communications services such as 3GPP IP Multimedia Subsystem (IMS) offer convenient IP based communication services. To create trustworthy services, such services sometimes offer security (encryption and integrity/authenticity) of the communication sessions. To enable such security it is beneficial if the necessary key management is included in the services, saving users trouble of manually configuring keys etc. Examples of such key management services are Kerberos based systems where a so called Key Management Server (KMS) provides keying material to users. 3GPP IMS (TR 33.328, included herein by reference) deploys a Kerberos-like key management server concept (MIKEY-Ticket, RFC 6043), albeit much more sophisticated and advanced. It will be appreciated that key management services can be used in any type of communications network. By way of example only, the following description focuses on 3GPP IMS networks. In an IMS context, communication services are RTP based and protected (for example, encrypted) using SRTP (IETF RFC 3711) and so the following description discusses RTP and SRTP. However, it will be appreciated that similar procedures may be applied to other security protocols such as TLS, IPsec, and so on, and also used to protect non-RTP communication (e.g. HTTP, MSRP, etc).
Kerberos based systems on a high level works as illustrated in FIG. 1. In FIG. 1, (x)y denotes an information element x protected, e.g. encrypted, by some key y. By some means, such as out of band communication, the Key Management Server (KMS) 1 shares keys with Alice 2 and Bob 3, K_A, K_B respectively. The KMS 1 also has another key, K′ (or means for generating such a key K′). Kerberos-like protocols use a concept of a “ticket”, used to carry cryptographic data such as keys, random nonces, cryptographic algorithms, etc. The following numbering corresponds to that of FIG. 1:
S1. Alice 2, wishing to communicate with Bob 3, sends a ticket request to the KMS 1, typically containing the identities of Alice 2 and Bob 3.
S2. The KMS 1 generates a random key, K, and encrypts it using Alice key, K_A and some other key, K′ (this may or may not be Bob's key K_B). This second copy of the key K is intended for Bob 3. The KMS 1 returns the two encrypted keys to Alice 2. Bob's copy is typically encoded as a “ticket” that may include other information (e.g. information as exemplified above).S3. Alice 2 can decrypt her copy of K (using K_A) and forwards the ticket to Bob 3.S4. Bob 3 asks the KMS 1 to “resolve” the ticket. This typically comprises the KMS 1 decrypting K (using K′) and re-encrypting it using K_B.S5. The re-encrypted copy of K is sent to Bob 3 from the KMS 1.S6. Bob 3 can now decrypt K (using K_B) and the key K is now shared between Alice 2 and Bob 3 who may use it to exchange protected (e.g. encrypted) data.
Note that some Kerberos variants use K′=K_B. In such situations, messages S4 and S5 may be omitted since Bob 3 then can resolve the ticket locally, using his already known K_B.
It should be noted that the KMS 1 used by Bob 3 and the KMS 1 used by Alice 2 may be two separate KMSs. If they are different KMSs, they must synchronize their data for the system to work. Specifically, as the KMS of Bob 3 receives message S4 (the “ticket resolve”), the KMS of Bob 3 will contact the KMS of Alice 2 (assuming the whereabouts of Alice's KMS, e.g. IP address, URL or the like, is encoded in the ticket) and ask for relevant information regarding K. The inter-KMS communication is typically also encrypted using IPSec or similar protocols, enabling secure transfer of K between the KMSs.
The 3GPP key management system, based on the above described Kerberos principle, works as follows. Messages are transported using HTTP but other protocols may be used (e.g. using Session Initiation Protocol, SIP, RFC 3261). An example network architecture and signalling is shown in FIG. 2, with the following numbering corresponding to that of FIG. 2:
Initially, a bootstrapping stage (not shown) occurs in which Alice 2 and the KMS 1 obtain a shared key, K_A. This can be done by out-of-band means or by using 3GPP GBA (TS 33.220) or the like. Similarly, Bob 3 and the KMS 1 also obtain a shared key, K_B, as shown in FIG. 1.S7. Alice 2, wishing to communicate with Bob 3, sends a (protected, e.g. authenticated) request to the KMS 1 for a “ticket”. This message may contain information about the communication session with Bob 3 and parameters necessary for security (algorithms, a nonce RAND_A, etc).S8. The KMS 1 checks that the request is authorized and if so generates a key, K_KMS_AB.S9. The key is protected (e.g. encrypted) using K_A and returned to Alice 2. The key is also encoded in a ticket, targeted for Bob 3, i.e. this ticket contains a copy of K_KMS_AB, encrypted by some key K′, similar to that shown in FIG. 1. Alice 2 can decrypt using K_A and recover K_KMS_AB.S10. Alice 2 transfers the ticket (and possibly other parameters, e.g. nonces) to Bob 3 via the session set-up signalling (e.g. SIP).S11. Bob 3 forwards the ticket to the KMS 1, asking the KMS to “resolve the ticket”. This message may contain further cryptographic parameters such as a nonce selected by Bob 3, RAND_B.S12. Resolving the ticket (in a manner similar to that shown in FIG. 1) means that the KMS 1 extracts (decrypts) K_KMS_AB using K′ and re-encrypting it using K_B.S13. A response is sent back which includes K_KMS_AB, encrypted by K_B. Bob 3 can now decrypt and recover K_KMS_AB.S14. Bob may now generate a response (e.g. encoded in a SIP message) to send back to Alice 2. This may contain Bob's 3 nonce, RAND_B and possibly other parameters.
At this point Alice 2 and Bob 3 share K_KMS_AB and other parameters, e.g. nonces, cryptographic algorithms, etc. In general any information included in the original ticket can now be assumed shared by Alice 2 and Bob 3. In particular, Alice 2 and Bob 3 can use K_KMS_AB as a basis to secure the SRTP communication by e.g. deriving SRTP encryption keys from K_KMS_AB and similarly configuring other parameters in SRTP, e.g. encryption algorithms, a salt etc. This is described in more detail in TS 33.328 and RFC6043 (MIKEY_TICKET, defining the details of the ticket handling).
When key management services such as those described above are offered as a service (e.g. by an IMS operator), it is, in most cases, a regulatory requirement for a Law Enforcement Agency (LEA) to be able to perform Lawful Intercept (LI) in order to prevent/solve crime, terrorism, etc. Note that LI here means the ability for LEAs to “eavesdrop” on the communication related to a target for LI, based on a warrant. Since the communication is encrypted, it does not suffice to only obtain access to the encrypted communication. The LEA also needs access to the keys used to encrypt/decrypt the communication. In general, the LEA will need access to all data/information needed to decrypt the traffic and it is typically the responsibility of the IMS operator to deliver this information. Alternatively, depending on specific national regulations, the IMS operator may decrypt and deliver un-encrypted traffic to the LEA. Nevertheless, knowledge of the decryption parameters is needed by the IMS operator.
For example, suppose that Alice 2 is making an IMS call (or in general some data/communications transfer) with another party Bob 3. Suppose further that the LEA issues a warrant to perform LI on communications involving Alice 2. There are now two cases to consider. At the point in time when the IMS operator receives the LI warrant, it can either be the case that:
1. Alice 2 has no current ongoing communications session (with Bob 3 or anybody else), or,
2. Alice 2 has already started a call, e.g. with Bob 3.
In either case, the requirement is that the LI shall be able to commence immediately. In case 1 this is quite simple. Whenever Alice 2 initiates a call, A will contact the KMS 1 and the KMS 1 (or some other entity in the operator's network) may already have been configured to deliver the key(s) and other information to the LEA. Similarly, other nodes involved in setting up communications (SIP servers, media gateways, etc) for A can be configured to “save” and “forward” necessary parameters to the LEA, including (encrypted) traffic. Case 1 can be covered by already known methods. In case 2, however, this will not work.
Currently, standard IMS networks are essentially “stateless” in the sense that they do not generally save parameters used during call set-up. Accordingly, it is therefore currently not possible to enable LI for a call/session that has already started: necessary parameters may no longer be available. A Kerberos-based solution, e.g. like the one defined by 3GPP, could in principle save a copy of the key, K_KMS_AB, previously delivered to Alice 2 (and Bob 3). When the LI warrant later comes, the KMS 1 can then deliver the key to the LEA. However, this is not enough for LI because the key alone is not sufficient to decrypt the media. Specifically, in any secure protocol (such as SRTP, TLS, IPsec, etc) the involved parties (Alice and Bob) do not use the key delivered by the KMS 1 directly. Specifically, they will derive a secondary key, based on the key from the KMS and “nonces” (known as “RAND” above) selected (pseudo) randomly by Alice 2 and Bob 3 without network control. In the IMS example shown in FIG. 2, a session key may take a form such as:K_session_AB=KDF(K_KMS_AB,RAND_A,RAND_B, . . . )whereK_session_AB: session key between Alice 2 and Bob 3 (used e.g. with SRTP)KDF: a key derivation function (e.g. HMAC_SHA256 based)K_KMS_AB: The key delivered from KMS to Alice 2 and Bob 3RAND_A: random nonce selected by Alice 2RAND_B: random nonce selected by Bob 3.
The nonces, RAND_A, RAND_B are typically sent between Alice 2 and Bob 3 during session set-up (e.g. included in SIP signalling, corresponding to messages S10 and S14 of FIG. 2).
Thus, the LEA would need to be given K_session_AB which requires knowing, besides K_KMS_AB, also (at least) RAND_A and RAND_B. Other parameters required may include further nonces, (e.g. in the case of SRTP a so called “salt” is needed to decrypt the traffic), other information required to specify initialization vectors (IV) for the encryption algorithm, and encryption algorithms: Alice 2 and Bob 3 may choose which algorithm to use from a set of allowed/supported algorithms. Knowledge of which algorithm Alice 2 and Bob 3 previously selected is thus needed to decrypt the communication by the LEA or elsewhere.
A solution to the above “mid-call-intercept” problem is proposed in 3GPP contribution SA3LI12_017 (ftp://ftp.3gpp.org/TSG_SA/WG3_Security/TSGS3_LI/2012_44_Barcelona/SA3LI12_01 7.zip). In this proposed solution the KMS shares not only K_A with Alice 2, but also a second key here denoted K_A′. Next, the solution proposes that Alice 2 does not select RAND_A at random, but rather as a (pseudo random) function of K_A′ and a new nonce N_A., for exampleRAND_A=F(K_A′,N_A)
This will enable e.g. KMS 1, to re-generate RAND_A if it is given access to N_A. To address this, the solution proposes that N_A is included in every SRTP media packet (as part of the packet header, e.g. the SRTP Master Key Identifier (MKI) field) sent between Alice 2 and Bob 3. Similarly, Bob 3 is also assumed to have a second key shared with KMS, K_B′ from which it generates its RAND_B using a nonce N_B. Hence, also nonce N_B needs to be included every SRTP packet.
If a LI request arrives at the IMS operator in mid-call (or session) between Alice 2 and Bob 3, some entity having access to media plane SRTP packets can extract the N_A, N_B values from the packets. Combining this information with K_A′ and K_B′ (available at the KMS) enables derivation of the keys used by Alice 2 and Bob 3, by first deriving the RAND_A and RAND_B values, and from them and the key K_KMS_AB (also obtained from the KMS) deriving the key corresponding to K_session_AB. This solution has several drawbacks:                It imposes a second shared key between Alice 2 (and Bob 3) and the KMS 1, adding to key management overhead/complexity.        It imposes restrictions on client implementations: they need to use a pre-defined method to generate RAND-values. This may lower the security level. Another contribution to 3GPP, S3-120175 demonstrated that a similar approach would reduce the security if used in conjunction with one particular key management scheme.        The bandwidth overhead is large. Each SRTP packet must include at least N_A and N_B. For security, these values should be of the order of 16 octets each, leading to 32 octet overhead per packet. This means a 50-100% overhead for typical audio SRTP packet sizes.        The solution is incomplete as it does not address how to retrieve other necessary parameters, e.g. the aforementioned SRTP salt, the cryptographic algorithms, etc. It is unclear if the need to retrieve also these values would further increase bandwidth overhead due to the need to encode even more information in each packet.        
In patent application US 2007/0297418 a method for lawful intercept is disclosed. This method is, like the aforementioned SA3LI12_017 based on the network keeping a copy of the key used by the users. A difference though is that this disclosure teaches that the network (intermittently) requests the keys from the users. As such, it would in principle allow mid-call interception. However, there are several drawbacks of such an approach. First of all, the network would need to more or less constantly poll the users for keys, to not allow a user to deduce from a key request that they are subject to intercept, since LI solutions have service requirements that users must not be able to do so. Secondly, the solution addresses only the need for keys and non-cryptographic data such as CODEC information, and does not handle other cryptographic parameters necessary for LI.